1. Technical Field
The present invention relates in general to firmware for systems and electronic devices and, in particular, to firmware upgrades. More particularly, the present invention relates to a method for identifying if a candidate firmware is compatible with an existing, or installed, firmware installation.
2. Description of the Related Art
Firmware is software codes which reside in a piece of hardware and are responsible for an integral portion of the hardware function and are generally treated as being a component of the hardware. Typically, firmware is stored as binary information in some form of nonvolatile memory component, in which binary can be represented in hexadecimal, octal and other number bases. The components of firmware may be executable programs, such as power-on self test (POST), Basic Input/Output Software (BIOS), configuration utilities, etc., or it may be data tables, e.g., a description of the geometry of a hardfile, register values to use with a universal asynchronous receiver-transmitter (UART) to produce different baud rates, etc. Firmware is typically stored in a special type of memory chip that doesn't lose its storage capabilities when power is removed or lost. This non-volatile memory is classified as “read-only” memory (ROM) because the user, during normal operation, cannot change the information stored there. Generally, ROMs are programmed at the “factory”, i.e., by the ROM manufacturer utilizing information provided by a customer. A basic type of memory device utilized to store firmware is called a programmable read only memory (PROM), which is programmable by any technician utilizing, e.g., a programming console. A basic PROM receives one version of firmware and the firmware code is “burned in” to the PROM and cannot be changed. To update the firmware, the PROM must be physically removed from the device and replaced with a new PROM that contains the upgraded firmware. Improvements in memory device technologies have rendered variations of the PROM, such as erasable programmable read only memory (EPROM) and electrically erasable programmable read only memory (EEPROM) devices, that can be erased utilizing electrical signals without the need to remove them from a circuit.
All products generally experience a number of firmware revisions that correct firmware defects, compensate for hardware or operating system errors or introduce new features. As long as the hardware architecture of the subsystem does not change substantially and each new firmware revision is capable of recognizing and dealing with differences in hardware revisions levels, things are relatively simple for the flash utility that replaces the present installed firmware image with a upgrade firmware image. The flash utility may assume that the progression of build IDs, such as QYKT24AUS, QYKT25AUS, etc., is valid and that older revisions may be applied over newer revisions, i.e., the level of the flash may regress, albeit with the possible loss of function and re-introduction of firmware defects.
However, certain events in the life-cycle of a product family break these simple assumptions. These events may include:
(1) Major changes in the architecture of a product, e.g., as a result of cost reduction changes, such that older versions of firmware do not recognize newer hardware features and therefore treat them improperly.
(2) The divergence of a product family into 2 or more related families, possibly under the control of two different engineering teams located, e.g., in distant cities, where the firmware may look similar but has actually been customized for a specific set of hardware.
(3) The convergence of two product families (from a firmware perspective). Convergence can be used as a cost reduction tool where two similar pieces of firmware exist and can be combined into a single firmware image that works on both hardware platforms but requires only a single development group to maintain and test it.
(4) A characteristic of a product, e.g., the layout of configuration information in CMOS memory, changes in such a way that older levels of firmware would misinterpret it.
Generally, systems and subsystems with updateable firmware typically require some sort of verification to determine applicability of a candidate image to an existing installation. Conventional methods quite often amount to nothing more than verifying some or all of the following: (i) a company's copyright notice exists in the candidate image; (ii) a part number in a recognizable form and position exists in the candidate image; (iii) a “type code” exists in the candidate image in a recognizable form and position and the type code indicates that the old and new images are compatible (type codes identify compatible types of hardware and may be applied to the overall product or to subsystems within the product); (iv) a revision level exists in the candidate image and that the user is attempting to apply a newer image over an older image; and (v) the candidate image has not been corrupted, e.g., verified by using a checksum or CRC. Items (i), (ii), and (iv) above do little (if anything) to aid in verifying compatibility between firmware images. They allow software utilities to verify that the firmware images came from a single vendor and that the user is not attempting to regress to an older firmware image. Even then, there are times when it may be desirable to regress so that a warning with a mechanism to override the protection is usually provided.
The limitations in the prior art generally centers on the use of type codes to indicate compatibility between images. The conventional techniques either do not utilize such type codes, in which case it is possible to inadvertently apply the wrong type of firmware image to a product, or assume that only firmware images within the same type code are compatible. Additionally, conventional techniques commonly require that an exact match exist between a single type code in the candidate image and a single type code in the installed image. Furthermore, the prior art techniques may also commonly assume that any new firmware images that present the same type code as an installed firmware image is compatible and may be utilized to update the installed image. These “simple” schemes often cause problems in the real world where complicated scenarios may arise. For example, these simple schemes are unable to deal with the following scenarios:
(a) A new component is introduced into a product line and requires new firmware to support it. The new firmware image will also work on older hardware but firmware images intended for the older hardware will not work (and should therefore not be allowed to update) on the newer hardware.
(b) For cost reduction reasons, two existing (and similar) firmware images (intended for slightly different hardware platforms) are combined into a single firmware image which will work on either of the hardware platforms.
(c) The firmware associated with a piece of hardware must be updated to one specific firmware image, which re-initializes some CMOS data areas, before other firmware updates may be applied to the hardware.
(d) The firmware associated with a piece of hardware must not be allowed to regress beyond a certain previous revision level because, e.g., the organization of CMOS memory utilized by certain previous revisions is incompatible with the present organization of CMOS memory.
Accordingly, what is needed in the art is an improved method of upgrading the existing firmware that mitigates the limitations discussed above. More particularly, what is needed in the art is a method for identifying if a firmware upgrade candidate image is compatible with the existing firmware image.